Triaging bugs is one of the easiest way to start
contributing to Debian. I ll teach you the basics in this article.
1. Prerequisites
All interactions with the Debian Bug Tracking System (BTS) happen through email so you need to have an email account with an address that you re willing to make public.
All the mail that you send to the BTS will be archived and publicly available through its
web-interface. This also means that you should have some spam filters in place because it will inevitably be harvested by spammers.
To ensure that this email address is consistently used by the various tools that we re going to use, it s a good idea to put this email address in the DEBEMAIL environment variable. You can also specify your full name in DEBFULLNAME (in case you don t want to use the name associated with your Unix account). You usually do this by modifying
~/.bashrc (if you use bash as login shell):
export DEBEMAIL="hertzog@debian.org"
export DEBFULLNAME="Rapha l Hertzog"
You should also install the
devscripts package, it provides the
bts command that we re going to use.
2. Find a package or a team with too many bugs
You can literally pick any popular software that s in Debian, they almost always get more bug reports than the maintainers can handle. Instead of picking a package, you can also select
a packaging team and concentrate your efforts on the set of packages managed by the team.
In any case, it s important to receive the bug traffic for the packages that you re going to work on. If you went for a specific package, you should subscribe to the package via the
Package Tracking System (there s a subscribe box on the bottom left corner once you selected the source package of interest). If you decided to help a team, there s usually a dedicated mailing list receiving all bug traffic.
You can browse a
list of packages with the most bugs if you have troubles finding a package to work on.
3. Triage bugs!
Bug triaging is all about making sure that bugs are correctly classified so that when a developer looks at the bug list, he can quickly find bugs with all the information required to be able to fix them!
3.1 Adding information to bug
Adding supplementary information is easily done just by sending a mail to
XXXX@bugs.debian.org (replace XXXX with the bug number).
But often you want to reply to a message in the bug history, in that case
bts --mbox show XXXX is for you. It will grab the corresponding mailbox and open a mailer (mutt by default) on it. Now you can directly reply in your favorite mailer.
3.2 Classifying bugs
The Debian BTS uses
tags (click the link and read the doc!) to classify bugs.
bts tag XXXX + foo will add the
foo tag (replace the + with a to remove a tag). If you want to explain why you re adding a tag, you should instead reply in the bug log as explained above, put control@bugs.debian.org in Bcc (Blind Carbon Copy) and start the body of your message with your tag command:
tag XXXX + foo
thanks
But what tag should you add? When a bug is submitted, you should try to reproduce the bug. If you can reproduce it, then tag the bug confirmed (example in
#641710). If you can t, you should request more information (ex: a sample document triggering the bug, a configuration file, the output of some relevant command, etc.) until you can reproduce it or conclude that it was a user mistake. When you request supplementary information due to this, you should tag the bug unreproducible moreinfo (example in
#526774). moreinfo should be later dropped when the requested information are provided, and unreproducible should be dropped if those information were enough to actually help reproduce the bug (example in
#526774).
During that initial evaluation, it s also worth differentiating packaging bugs (which are specific to Debian) from upstream bugs (which are relevant also for non-Debian users). The latter should be tagged upstream (and forwarded upstream if the bug is reproducible or contains enough information for the upstream developers, example in
#635112).
If you saw a (viable) patch in the bug log, the bug should be tagged patch . This is usually done by the patch submitter but sometimes it s forgotten (example in
#632460). Take care though to not reinstate the patch tag if it was initially set but then dropped by the package maintainer after a review of the patch.
If the title of the bug report is not descriptive enough, you can change it with a
retitle XXXX new-title command (example in
#170850).
You can also change the severity of the bug report depending on the impact of the problem (with a command
severity XXXX new-severity , what a surprise!). Request for new features are wishlist , most documentation problems are minor . On the other side of the scale, you can use important for bugs that are very annoying but that should not block a release. serious , grave and critical are used for
release critical bugs, check the
official definitions of the severities (examples in
502738 or
#506498).
3.3 Closing non-bugs and bugs that are already fixed
If your analysis of the bug report is that it s not really a bug but a user mistake, then you should close it by sending a mail to
XXXX-done@bugs.debian.org with some explanations of the user s mistake so that he can get past his problem (example in
#592853).
If the problem was a real bug, but one that is apparently already fixed, you should try to quickly find the version that fixed the bug. If you can t find it in the changelog (there s a link to it in the PTS, or you can use /usr/share/doc/
package/changelog.Debian.gz), you ll make the safe assumption that the upstream version you re currently using is the first one where this is fixed. Then you send a mail to
XXXX-done@bugs.debian.org but you start your mail with
Version: version-that-fixed-the-bug and continue with a small explanation of why you believe the bug to be fixed by this version (example in
#122948).
3.4 Reassigning misfiled bug reports
Bug reports are not always filed against the proper package. Users file bugs against applications where they experience the bugs, but the real bug might be in an underlying library or application.
When that happens, you should use the
reassign XXXX correct-package version command to get it filed against the correct package. The
version parameter is optional but should be provided if possible, it should be the oldest version that we know to have the problem (example in
#626232).
3.5 Forwarding bugs
Forwarding bugs means opening bug reports in the upstream bug tracker for issues that have been reported in Debian but that applies to the upstream (unmodified) source code. Be sure to include all the relevant information and a link to the corresponding Debian bug.
Depending on the upstream bug tracker, you might have to open an account to be able to file new bug reports.
On the Debian side, you must record that a bug has been forwarded with
bts forwarded XXXX upstream-bug-url .
upstream-bug-url is the URL corresponding to the upstream bug report you created (ex:
http://projects.ciarang.com/p/feed2omb/issues/21/ recorded in
#609345 ).
If the upstream authors fix the bug you reported, you can tag the Debian bug with fixed-upstream so that it s easier to find bugs to close when the next upstream release comes out (example in
#637275).
3.6 Updating version information
The Debian BTS uses version tracking to know which package versions are affected by a given bug. It s particularly important to have correct version information for release critical bugs since it might affect the migration of packages to testing.
You can learn more on this topic here:
http://wiki.debian.org/HowtoUseBTS.
4. More advice
Colin Watson wrote a
constructive rant explaining some mistakes that bug triagers are often doing. While it refers mainly to Ubuntu s launchpad, the advice apply equally as well to Debian. Check it out to become a better bug triager!
Note that you can refer to this article with this shorter URL:
http://raphaelhertzog.com/go/bugtriaging/
Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.
One comment Liked this article? Click here. My blog is Flattr-enabled.
here comes my usual report about my work on RC bugs. this time a bit more
"added a comment" or "sent a patch" but also some uploads.
I've managed to go for eleven years working on Debian and nearly eight on Ubuntu without ever needing to teach myself how APT's resolver works. I get the impression that there's a certain mystique about it in general (alternatively, I'm just the last person to figure this out). Recently, though, I had a couple of Ubuntu upgrade bugs to fix that turned out to be bugs in the resolver, and I thought it might be interesting to walk through the process of fixing them based on the 
Last year I shared my 
On Saturday evening I started talking with 
Dpkg: Multi-Arch Saga
I know lots of people are waiting the landing of multiarch in Debian unstable, and so am I. Things are progressing, though not as quickly as I hoped. Guillem merged about half of the branch between the 24th October and the 6th of November. After that most of the work happened on his personal repository in his 
In both cases, I have been in contact with members of the release team because those ideas require some structured data from the release team as input. Thanks to Meddi Dohguy and Niels Thykier for their help.
Later in the month, the topic of relocating the PTS once again came up. For historical reasons, the PTS was hosted on master.debian.org together with the BTS. Nowadays the BTS has its own host and it made no sense anymore to have the PTS separate from the rest of the QA services hosted on qa.debian.org (currently quantz.debian.org). So together with Martin Zobel Helas we took care to plan the migration and on November 19th we executed the plan. It worked like a charm and almost nobody noticed (only one undocumented dependency was missed, which 
Ubuntu has had an explicit goal for several cycles now to achieve
flicker-free booting: smooth graphical boot all the way through from
bootloader to the desktop, with no messy modeswitches or cuts between
text and graphics mode on the console. This is no small task, to be
sure; even getting flicker-free transitions between plymouth and X for
the KMS-capable video cards was a handful for 10.04 LTS.
So I was suitably impressed when in the course of testing for the
upcoming 
eysler.debian.org is now DSAed, online and building packages (including
autosigning). I will shutdown monteverdi.ayous.org which is still at my
place in the next days, reinstall the system and send it to Darmstadt as
another buildd for data center hosting there. After that happens all mipsel
buildds are DSAed as it should be, and are running in a data center and not
via some DSL line.
(In case you're looking for hardware at your place, there are a couple of
loongson 2f-systems available to buy. 2f is the successor cpu of 2e. Some
2f systems get delivered with Debian installed on it, see e.g.
Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in